Internet Info 1993

home *** CD-ROM | disk | FTP | other *** search

/ Internet Info 1993 / Internet Info CD-ROM (Walnut Creek) (1993).iso / inet / internet-drafts / draft-ietf-nasreq-nasrequirements-01.txt < prev next >

Wrap

Text File | 1993-07-08 | 32.8 KB | 989 lines

INTERNET-DRAFT John Vollbrecht Allan Rubens Glenn McGregor Larry Blunk Richard Conto Merit Network, Inc. July 1993 Expires January 1994 Network Access Server Proposed Requirements Document Status of this Memo This document is written as input to the Network Access Server Working Group. It describes a Network Access Server and its role in providing temporary access to a network. The document focuses on needs for authentication, authorization and accounting support. This revision of the document is still very much of a working document. The document includes an overview of NAS requirements, a description of the authentication and authorization environment that a NAS is expected to interact with, a brief architecture description, and a set of requirements matched with the architecture. The requirements are still at a fairly high level and need details filled in. New concepts introduced in this version include a "helper" that acts as an intermediary between the NAS and a variety of authentication, authorization and tracking servers, and the idea of having a "connection server" which could manage connection dialog for the NAS and use a refined Telnet redirect to request the NAS telnet client to connect to the appropriate destination In addition, appendices deal with authentication, authorization, and useage tracking issues as they apply to the NAS. This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by NAS Requirements [Page i] INTERNET-DRAFT July 1993 other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a ``working draft'' or ``work in progress.'' Please check the 1id- abstracts.txt listing contained in the internet-drafts Shadow Directories on nic.ddn.mil, nnsc.nsf.net, nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au to learn the current status of any Internet Draft. NAS Requirements [Page ii] INTERNET-DRAFT July 1993 1. Introduction This document defines a set of requirements for a class of devices referred to as Network Access Servers (NAS's). The term "Network Access Server" is used instead of the more conventional term "Terminal Server" as it more accurately describes the devices of interest. This is written as input to the NAS requirements working group of the IETF. A Network Access Server (NAS) is a router or terminal server which provides temporary access to a network. It can provide access for both traditional "dumb terminals" and terminal emulators as well as workstations, PC's or routers utilizing a serial line framing protocol such as PPP or SLIP. Thus a NAS can provide connections to a single user, to a network or subnetwork, or to interconnected networks. The entities that use the NAS to connect to a network are called Network Access Clients (NACs). The NAS may be a system dedicated to providing temporary network access, or it may be a part of a system which has other capabilities as well. For example a workstation with a set of dial-in lines could provide NAS functions. The physical attachments to a NAS, which are used for temporary connections, will typically be dial-in modems attached to local phone lines, but could also be a hardwired connection supporting ISDN, frame relay, or other switched (virtual) circuit services. The purpose of this document is to define the requirements for functions and services that a NAS should provide to both its administrators (the people responsible for deploying and managing the NAS) and its clients (the PCs, workstations and routers that connect to the network through the NAS). Many of the requirements of a NAS are identical to what is required of a router. In fact a NAS can be viewed as a special class of router, one in which the "neighbors" are not permanently attached. When an attachment request is received, the NAS must insure that the new "neighbor" is authorized to attach. This is contrasted with a conventional router where a "neighbor" is permanently connected. The application of this model to the character stream ("dumb terminal") case requires that a "packetization" process convert between the character stream and packet formats. In this case the "neighbor" of the router is the packetizing client. A typical packetizing client would be the Telnet client. The figure below shows a model of this. NAS Requirements [Page 1] INTERNET-DRAFT July 1993 NAC network attachment internal packet attachment process(es) interfaces router(s) process _______________________________________________________ | ________ | | | | | character | | Telnet | | mode -----|-----| Client |\ | | |________| \ | | \ _____________ | | \_()_____| | ________ | | | | | | | | | ROUTER |__|Ethernet|-|-- | ________ --()------| | |________| | framed | | | / | | | input ----|-----| PPP |/ |_____________| | | |________| | | | | | |_______________________________________________________| Figure 1 NAS structure In the above model there are NAC attachment processes which are responsible for handling incoming data. Not shown, but necessary for dial-in async input, is a process which will switch input to the appropriate input process (e.g. a way to distinguish between a character stream input and PPP input at the time a connection is initiated). The figure shows two user attachment processes, but there could be many different ones to support SLIP, ISDN, etc. The internal router interface is the point where service authorization is implemented. Here routing configurations, packet filters and such are applied. The implementation of these may be different at a PPP interface than at a Telnet Client interface. For example, a PPP interface would restrict packets by applying filters to each packet, while the Telnet interface might check for access privileges only when it is establishing a TCP connection. The router process forwards packets. There may be several processes which route packets, each using different routing protocols. It is likely that a NAS will route other protocols, such as IPX, CLNP or Appletalk, in addition to IP. The network attachment process is similar to the framed input attachment process, except that it is configured as part of the NAS, and its capabilities are not modified with new connections. The network attachment process could support an ethernet connection, as NAS Requirements [Page 2] INTERNET-DRAFT July 1993 shown in the figure, a dial-out PPP connection, a synchronous serial line, or some other network attachment mechanism. (Note that if the network attachment is via a dial on demand port, the NAS must be configured to know which remote router(s) to dial for network connection. If a remote router dials into the NAS, then the NAS can treat it similarly to any other dial-in port except that it must set up routing to the network itself, and will probably require mutual authentication between routers) 2. NAS Environment A NAS can be used in a wide range of environments. It could be a front end for an individual host, it could provide access to a LAN for a limited set of users. The case we are interested in is where it provides a large community of users belonging to a number of different organizations with access to a network which interconnects hosts from a number of organizations. This is the case where a regional IP network provides dial-in access for its users. The dial-in access allows connection to the regional net and through it potentially to other networks on the international Internet. The regional might provide dial-in access at a number of geographic locations in order to limit costs of dialing. As described here, the user (terminal, workstation or router) is the Network Access Client (NAC). The NAC requests to be connected to the network, and the NAS accepts or rejects the request. The NAC must be authenticated and authorized by servers which can typically only be reached through the NAS. A NAS may want to identify a NAC by doing an authentication check at the NAC's home organization. Once the NAC is authenticated, it may also be desired to check the network capabilities for which the NAC is authorized. The sort of capabilities a NAS provides include protocols for access (e.g. PPP, IP, IPX, dumb terminal, telnet, rlogin), what addresses are accessible from the NAC's port, and other NAS specific functions that may be provided. This does *not* include limits on what print servers, file servers, or other host capabilities may be supported, other than by possibly restricting access to destination addresses at which the servers reside. A NAS is a Network Access Server, not a frontend to a set of servers or hosts. In the envisaged environment a NAS will need to authenticate a NAC at the authentication server supported by the NAC's organization. Each NAS Requirements [Page 3] INTERNET-DRAFT July 1993 organization may support a different authentication mechanism. Some may use Kerberos, some may use Unix password files, some may have other mainframe based authentication mechanism, and others may use a Public certificate system. A NAS will need to be able to interact with whatever authentication servers are used at different organizations. It is not reasonable to expect that an organization will move tens of thousands of userids and passwords to a different authentication system to allow the regional to use a NAS that supports only a particular authentication mechanism. Authorization servers will be run by the organization running the network, and may be more closely tied to the NAS. For authorization the NAS may also need to interact with authorization servers at the NAC's home organization to be sure the NAC is authorized by its own organization to uset the NAS. It is desirable for the NAS to use some "standard" authorization service. Finally, a NAS will need to track useage for Accounting and auditing purposes. Accounting information will need to be forwarded to a number of different auditing/billing systems supported by different organizations. 3. NAS architecture A NAS consists of a set of ports which connect Network Access Clients and networks. NAS processes take data from the ports, packetize/depacketize it appropriately, and route packets between ports. This is what is shown in Figure 1. In addition, a NAS has "management" processes that are needed to perform the following tasks 1. NAC identification and authorization 2. Per NAC useage tracking for auditing and accounting 3. collecting and reporting performance and load measures 4. debugging 5. configuration of NAS 6. loading and dumping 7. call initiation dialog 8. stuff that we have forgotten or not thought of yet A NAS will hopefully be an inexpensive box. The processes that support NAC identification and authorization and useage tracking may be complicated, mostly because of the number of ways different organizations may choose to do these. Thus a NAS might have to implement Kerberos, Unix password support, and Public Key Certificate NAS Requirements [Page 4] INTERNET-DRAFT July 1993 authentication depending on the user. To make this simpler for NAS suppliers to implement and support, a "helper" process is included in the architecture. The "helper" interfaces to the different authentication, authorization and useage tracking systems. It communicates with the NAS using a simple standardized protocol. In addition to making implementation and support simpler, it provides a mechanism by which a NAS can adapt to evolving authentication and authorization standards. The "helper" can also be adapted to perform additional functions that might not be justified in a standalone NAS, for example it might support custom connection dialogs for character stream NACs. The "helper" may reside physically on the same hardware as the NAS, or it may be on a remote workstation. It is possible that if the NAS/helper protocol becomes widely accepted that public domain versions of "helper" implementations will become available to interface with most authentication and authorization servers. The following figure gives a view of the proposed NAS architecture. The numbers in this diagram indicate the section below which describes the particular interface. / useage tracking servers / /- authorization servers / /--- authentication servers 4.3- "helper" - / NAC --- 4.1 - NAS 4.2-- Network | 4.4 \------- call initiation - (remote selection) \ \----- performance statistics \ \---- debugging \ \-- config \ \ load/dump NAS architecture elements NAS Requirements [Page 5] INTERNET-DRAFT July 1993 4. NAS requirements The following details requirements for each of the interfaces indicated in the above architecture. The sections are not complete and need to be completed/reviewed by the nasreq working group. 4.1. NAS - NAC interface 4.1.1. Detecting type of call Need a way to detect at call initiatiation whether the NAC is doing character stream or PPP input. (details of one way of doing this will be provided) 4.1.2. NAC Authentication (see appendix for overview) 4.1.3. Character Stream authentication NAC doing initial connection with character stream data should be able to authenticate using -id/pw -smartcard -other? 4.1.3.1. PPP authentication authentication using PPP should be supported via -PAP -CHAP -Kerberos Challenge -Public Key Challenge 4.1.3.2. Mutual Authentication The NAC may need to confirm that it has connected to the correct network. The NAS will need to have a certificate or token that it can show to the NAC which proves the NAS is acting for the network. NAS Requirements [Page 6] INTERNET-DRAFT July 1993 4.1.4. Character Stream clients A NAS may support telnet, rlogin, tcp passthru, other 4.1.5. PPP input process PPP input process should support IP may support IPX, Appletalk, Vines, OSI, bridging 4.1.6. IP Address assignment 4.1.7. Per Packet Address filtering 4.2. NAS - Network interface 4.2.1. Interface - ethernet, token ring, FDDI, synchronous PPP, 4.2.2. Protocols - IP required, IPX/ Appletalk/ Vines/ OSI 4.2.3. Router Process Must support IP routing. RIP, OSPF 4.3. NAS - helper interface This is being specified as part of the working group process. The protocol must allow information to be transferred between NAS and "helper" reliably, passwords must not be sent in the clear. "Must not present security exposure greater than already presented on NAC/NAS interface". 4.4. Management processes 4.4.1. SNMP The NAS must support SNMP. Standard MIB2 entries, plus additional support for hunt group utilization. Should be able to support modem mib. It may be requested that configuration information, such as additions or deletions from packet filtering lists, be done via SNMP NAS Requirements [Page 7] INTERNET-DRAFT July 1993 4.4.2. Debugging The NAS should support an out of band access capability that allows access to local debugging tools. 4.4.3. Configuration The NAS should be able to be reconfigured over the network without rebooting. 4.4.4. Load/dump There needs to be a secure load/dump mechanism. 4.4.5. Call initiation At call set up using dumb terminal mode, authentication and authorization of the NAC to the NAS should be independent of authentication and authorization of sessions to remote hosts. For example, a NAC would have to give a password and id to establish that it is ok for it to connect to a local telnet client. The NAC would then telnet to a remote host which would also require the NAC to identify itself. A NAC/NAS session may support multiple packetizing sessions. For example a NAC might establish a connection to a NAS and then connect to serveral telnet client processes, each of which connects to a different remote host. At call set up the NAS may pass the connection to a "connection server" which could present an individualized connection/help menu. The connection server could then use a "cleaned up" telnet redirect message to have the NAS extablish a connection to the appropriate host/port. Note that authorization to make the connection would need to be applied before the NAS actually initiated it. This requires clean up of the telnet redirect definition. The security implications of this have not been well thought out yet. It is important that a NAS not accept a redirect request from anyone except the "connection server" or its agent. NAS Requirements [Page 8] INTERNET-DRAFT July 1993 Appendix A Authentication Overview and Alternatives 1. NAC/NAS authentication NAC/NAS authentication will be done in one or more of the following ways. a) userid/pw - this is the most primitive, and has the pw in the clear between NAC and NAS. It is by far the most common mechanism at this point. b) one-way challenge authentication - this authenticates the NAC to the NAS using a challenge/ challenge response algorithm. Three algorithms are discussed below. c) mutual authentication - the NAC is authenticated to the NAS and the network/NAS is authenticated to the NAC. The algorithms for this may need some further work, but three approaches are discussed below. The assumption is that a NAS vendor will implement one or more of these authentication mechanisms and users will buy what is best for their application. The intent is to specify what protocols will be used at each level so that implemetations from different vendors of that level will interwork. The following descriptions are oriented to using PPP authentication mechanisms. Adapting these to character stream input is left for a later document. The nasreq working group should pass responsibility for detail formulation of the PPP protocols to the PPP working group or to a joint PPP/NAS/security group. The following discusses the authentication options in more detail. a) passing userid/pw from NAC to NAS. This can be done for character stream connections using a prompt sequence. For PPP it will be done via PAP. The protocol sequence (for PPP) NAC->NAS: userid/pw NAS_>NAC: ACK/NAK The NAS can take the userid/pw combination and access almost any NAS Requirements [Page 9] INTERNET-DRAFT July 1993 authentication server as proxy for the NAC. This has the problems that the pw is in the clear betweent the NAS and NAC. The NAS also has the pw in memory for some time so it may be vulnerable to other attacks. On the other hand, it is simple, it exists now, and it is better than nothing (at least for the short term). b) a challenge protocol to authenticate NAC to NAS This is the class of authentication that includes CHAP. With this approach the protocol sequence between the NAC and NAS follows the model below. NAC->NAS: userid NAS->NAC: challenge NAC->NAS: challenge response the challenge may be repeated periodically. This eliminates the password in the clear problem. The CHAP implementation is done in PPP, and the others need better definition, but appear not to be a big change to PPP. Three different challenge /response mechanisms have been suggested 1) CHAP - NAC and NAS know a common secret and use it to generate and evaluate the response to a "challenge". In PPP implementations the expectation is that the NAS may send the challenge information and response to a third party CHAP server which keeps the common secret for each NAC and returns a yes or no response back to the NAS. 2) Kerberos version - NAS goes to Kerberos server to get a session key to be used by NAS and NAC. The NAC gets its key n in the challenge sent by the NAS, encrypted in its key. The challenge response is generated with the received key. The intent of this is to allow the NAC to use a Kerberos server that is available at his site in the authentication process. It means that it can have one secret to maintain and remember rather than many. One sequence that might be used to support this is as follows (the statements with * at the start are the actual NAC/NAS protocol statments): NAS Requirements [Page 10] INTERNET-DRAFT July 1993 *NAC->NAS: userid NAS->authS: userid,NASid authS->NAS: {sesskey,userid,{sesskey,NASid}*kNAC}*kNAS NAS: decrypt using its key (kNAS), keep session key, userid *NAS->NAC: challenge, {sesskey,NASid}*KNAC NAC: decrypt using its key (KNAC) respond to challenge using sesskey (common session key) *NAC->NAS challenge response NAS: uses saved sesskey and userid to validate the response *NAS->NAC ACK/NAK 3) Public Key certificate version - similar to Kerberos but uses Public key certificate. The intent is to allow use of public key certificate distributions systems to authenticate NAC to NAS. The NAC uses his private key to "sign" a challenge, which is then checked by the NAS using the NAC's public key. The following indicates one way this could be done. *NAC ->NAS: userid *NAS ->NAC: challenge *NAC ->NAS: challenge*NACprivate-key NAS: get certificate with public key of userid verify NAC's response *NAS ->NAC: ACK/NAK c) mutual NAC / network authentication - In this case the NAC and network (via the NAS) mutually authenticate each other. This mechanism needs further definition, and should probably be directed to a group with more depth in security issues. NAS Requirements [Page 11] INTERNET-DRAFT July 1993 One approach to mutual authentication is to run the algorithms twice, once in each direction. For CHAP with a shared secret that might be workable. However, it seems that it should be possible for the NAC to authenticate to a "network" rather than a specific NAS. In fact the NAC may have no idea which NAS it is calling. Typically a list of dial-in numbers would have a provider name rather than a NAS id associated with it. A dial hunt group might be spread accross several NASs. The following are meant to give an idea of how something like this might work rather than be a definitive design. However in the interest of stimulating discussion, the following are presented. 1) mutual authentication with CHAP *NAC->NAS: userid,netchallenge NAS: use common secret to generate response to netchallenge *NAS->NAC: userchallenge,netchallenge-response NAC: use common secret to generate response to userchallenge *NAC->NAS: userchallenge-response *NAS->NAC: ACK/NAK note that this fits the same protocol framework as the one way authentication. If the NAS goes to a third party CHAP authentication server then all NASs that use that server will look the same to the NAC. 2) mutual authentication with Kerberos In this mechanism the assumption is that the NAS gets a ticket granting ticket for a ticket granting server that knows all NACs. *NAC->NAS: userid, netid,netchallenge NAS->authS: userid,NASid authS->NAS: {ksess,userid,{ksess,NASid}*kNAC}*kNAS NAS: decrypt using kNAS, keep ksess, userid use ksess to create reply to netchallenge *NAS->NAC: {ksess,NASid}*kNAC, netchallenge-response, userchallenge NAC: decrypt using kNAC, keep ksess, NASid use ksess to evaluate netchallenge-response use ksess to generate response to userchallenge *NAC->NAS: userchallenge-response *NAS->NAC: ACK/NAK This again is the same message sequence as before, but with different content in some of the messages. If the authS knows both the NAS and NAC and will not authenticate anything other than a NAS having the NAS Requirements [Page 12] INTERNET-DRAFT July 1993 NAC (somehow - for futher study) check to see that the NAS is in fact authorized by the network to act on its behalf. 3) mutual authentication with public key certificates *NAC->NAS: userid, netid, netchallenge *NAS->NAC: userchallenge, netchallenge*NASK, NAS-net-certificate *NAC->NAS: userchallenge*KNAC, *NAS->NAC: ACK/NAK In this mechanism, the NAS and NAC use their private keys to sign a challenge. The NAS gets the public key of the NAC from a certificate server. The NAS sends the NAC a special, to be designed, certificate that includes the public key of the NAS signed by a network certificate provider. It also certifies that the NAS is authorized to act for the netid network. The NAC must know the public key of the certificate provider ahead of time, or have some other way of finding out. NAS Requirements [Page 13] INTERNET-DRAFT July 1993 Appendix B Authorization 1. NAS / network authorization The NAS may need to be authenticated to a variety of authentication and authorization servers in order to make authorization/authentication requests for the NAC. This will be done using standard authentication protocols. This needs more detailed definintion. 2. Authorization of NAC Once the NAC is authenticated, the NAS will need to determine what the NAC is allowed to do. Two approaches to deciding what is appropriate have been discussed. a) Get a list of what the NAC is allowed to do and give it to the NAS. This has been described as per NAC configuration. b) Each time the NAC requests a new service (e.g. telnet to x.y.z) ask a authorization server if it is allowed. This has been described as the access control or authorization server approach. 3. Virtual networks One major authorization requirement is to restrict a NAC's access to a particular set of destinations on the network. For IP users this is typically controlled by setting packet filters. Some different approaches to how to set up and administer these filters have been discussed. Having a set of filters that is unique for each user gives the most flexibility, but could be very time consuming and error prone for large populations of users from different organizations. Alternatively a number of named filter sets could be set up and each NAC would request authorization to use one or more set. This can be thought of as setting up a number of virtual networks which the NAC may or may not be authorized to access. Currently this approach seems to be favored. NAS Requirements [Page 14] INTERNET-DRAFT July 1993 Appendix C Useage Tracking/Accounting A NAS must create tracking records to allow tracking each NAC/NAS connection session. For each session there should be a unique session ID which is included in the header of each record for that session. A tracking record should be generated at the time a NAC makes initial connection to the NAS, when the connection is terminated, and for special events during the session. Some of the special events that need tracking records are 1) establishing a telnet/rlogin/etc connection from NAS client to a remote node 2) terminating a telnet/rlogin/etc connection from NAS clientto a remote node 3) checkpoints - same information as end of session records in case an end of session record should get lost. In addition to session records, tracking records should be generated for NAS system events including: 1) NAS startup 2) unsuccessful connection attempts (note that if id/pw fails the id should not be recorded to avoid recording passwords typed in out of sync) Tracking records should be sent to one or more collection servers. Each record should contain character and packet counts, unique session id, NAC id, NAS port, IP address, date-time of session start and of record generation, frame and packet protocol types (e.g. PPP/IP). Telnet/rlogin/etc tracking records will have as additional information the destination address/port, client type, and userid. This needs to be spelled out better in conjunction with ietf accounting wg. NAS Requirements [Page 15] INTERNET-DRAFT July 1993 Authors' Addresses John Vollbrecht email: jrv@merit.edu Allan Rubens email: acr@merit.edu Glenn McGregor email: ghm@merit.edu Larry Blunk email: ljb@merit.edu Richard Conto email: rsc@merit.edu all Authors may be reached as follows Merit Network, Inc. 1071 Beal Ave Ann Arbor Mi. 48109 Phone: (313) 936-3000